callback_threshold is a uint64_t, but it is logged with %lu here. On LLP64 platforms (Windows), unsigned long is 32-bit, so this truncates the value and (with the new format checking) can trigger a format/type warning. Use PRIu64 (or %llu with an explicit cast to unsigned long long) for this argument.

soh_withheld_budget/loh_withheld_budget are size_t but are logged with %lu. This is not portable (on Windows size_t is 64-bit but unsigned long is 32-bit) and will also be flagged by the new printf format validation. Use %zu (or cast to an appropriately sized unsigned type) for these values.

totalBlocksScanned is declared as int64_t, but is printed using %ld (and the related per-generation counters are printed with %ld too). On Windows long is 32-bit, so this truncates and is a format/type mismatch under printf checking. Use PRId64/PRIi64 (or %lld with casts to long long) consistently for these 64-bit counters.

elapsed is a uint64_t, but the log uses %ldus/%ldms. This is non-portable (Windows long is 32-bit) and will be flagged by printf format validation. Prefer PRIu64 (or %llu with casts) for the timestamp and derived values.

sample.elapsed_between_gcs is a uint64_t (see dynamic_heap_count_data_t::sample in gcpriv.h), but is logged here with %ld. This truncates on LLP64 and is a format/type mismatch with the new printf validation. Use PRIu64 (or %llu with cast to unsigned long long) when printing this value.

This log now uses "%p" for libFileName, which prints the pointer address rather than the invalid module name. That makes the diagnostic much less useful. Consider converting libFileName to UTF-8 (similar to later libPath.GetUTF8()) and logging it with "%s", or otherwise logging the actual string value.

PRIx64 comes from <inttypes.h>, but in C++ builds some standard libraries (notably glibc) only define the PRI* format macros when __STDC_FORMAT_MACROS is defined before including the header. To avoid portability/build breaks, consider defining __STDC_FORMAT_MACROS (guarded) before including <inttypes.h> here (or include an existing header that does so).

Same portability concern as other PRI-macro changes: in C++ mode <inttypes.h> may not expose PRIx64 unless __STDC_FORMAT_MACROS is defined before the include. Please ensure this is defined (guarded) prior to including <inttypes.h> so the PRIx64 usages below compile on all Unix libc implementations.

Same issue as other PRI-macro additions: for C++ compilation, <inttypes.h> may not define PRIx64 unless __STDC_FORMAT_MACROS is set before including it (common on glibc). Please ensure __STDC_FORMAT_MACROS is defined (guarded) before this include to avoid build breaks.

This file now includes <inttypes.h> to use PRIx64, but in C++ builds those PRI* macros may be hidden unless __STDC_FORMAT_MACROS is defined before including the header (notably on glibc). Please ensure __STDC_FORMAT_MACROS is defined (guarded) before the <inttypes.h> include to keep Linux builds working.

<inttypes.h> is included here for PRI* format macros, but in C++ mode some libcs only provide those macros when __STDC_FORMAT_MACROS is defined before the include. Please ensure __STDC_FORMAT_MACROS is defined (guarded) prior to including <inttypes.h> so these PRIu64/PRId64 uses compile portably.

This translation unit now relies on PRI* macros via <inttypes.h>, but in C++ builds they may not be visible unless __STDC_FORMAT_MACROS is defined before the include (common on glibc). Please define __STDC_FORMAT_MACROS (guarded) before including <inttypes.h> to avoid portability/build issues.

The log label size=%g is currently printing m_PerCallInstructionEstimate / SIZE_SCALE, which is an instruction-count estimate rather than the size impact (and doesn’t match the size label). This looks like an accidental argument change when fixing the varargs mismatch—should likely print m_ModelCodeSizeEstimate / SIZE_SCALE, or update the format string to include both instruction and size estimates explicitly.

input->version_lo is a size_t (see host_interface_t), but this log uses %zd (signed). With the new printf-format annotations on trace::verbose, this should be %zu (or cast to ssize_t if negative values are intended).

input->version_lo is size_t, but the error message formats it with %zd. This should be %zu to match the type and avoid incorrect output / format warnings now that trace::error is printf-annotated.

The g_error format string uses %lld for ts.tv_sec, but tv_sec is time_t (commonly long), and this call doesn't cast it. Please either use the correct specifier for time_t (e.g., %ld where applicable) or cast ts.tv_sec to long long to match %lld to avoid varargs type mismatch.

In DumpILInstruction, pInstruction->uArg is UINT_PTR. Formatting it via 0x%lx / 0x%08lx after casting to unsigned long can truncate on Windows 64-bit (where unsigned long is 32-bit) and reintroduces platform-specific formatting. Prefer printing UINT_PTR via PRIxPTR (with a uintptr_t cast) or another pointer-width specifier used elsewhere in the repo (e.g., %zx with (size_t)), so the value is correct on all targets.

This 0x%08lx formatting has the same UINT_PTR truncation risk as above on Win64 (where unsigned long is 32-bit). Even if current opcodes typically use 32-bit tokens here, using a pointer-width-safe format (or explicitly casting down to uint32_t when that’s the intent) would avoid future issues and keeps the printf-attribute checking accurate.

The log message now prints the pointer value of libFileName (%p) rather than the invalid GC module name/path itself, which makes the diagnostic much less useful. Since libFileName is LPCWSTR, consider converting to UTF-8 (e.g., MAKE_UTF8PTR_FROMWIDE) and logging it with %s, similar to the other standalone GC logging in this file.

ts.tv_sec is time_t (not necessarily long long). Using %lld here without casting can be UB and will still trigger format warnings on platforms where time_t is long (common on Linux). Consider either using %ld consistently, or cast ts.tv_sec to long long (and do the same in the pthread_cond_timedwait_relative_np branch) or use an inttypes.h/GLib format macro with an explicit cast.

This header adds a new __GNUC__ / __attribute__((format)) block directly on ERR_set_error, even though the PR introduces MINIPAL_ATTR_FORMAT_PRINTF to centralize this pattern. If feasible for this component, prefer using the shared macro (and include the header that defines it) so format-attribute usage stays consistent and avoids duplicated compiler-ifdefs.

%llx expects an unsigned long long, but m_offset_in_file is int64_t and is currently cast to long long. With the new printf-format checking enabled on trace::info, this can still warn and is technically UB. Prefer casting to unsigned long long (or uint64_t + PRIx64) to match the specifier.

Same issue as above: %llx expects unsigned long long, but the argument is cast to long long while m_offset_in_file is int64_t. Consider using an unsigned cast (or PRIx64) to align the argument type with the format specifier and avoid UB/warnings.